1. Technical Field of the Invention
The invention relates in general to congestion handling of a packet switched network domain. In particular, and not by way of limitation, the present invention is directed to congestion handling in an Internet Protocol (IP) network domain.
2. Description of Related Art
Recently, IP-based transport solutions are considered for 3rd generation (3G) networks because of the flexibility and wide deployment of IP technologies. These networks have different characteristics when compared to traditional IP networks requiring fast dynamic resource reservation, simplicity, low costs, severe congestion handling, and good scalability properties. Besides, 3G networks have strict Quality of Service (QoS) requirements. Traffic congestion control is thus an important consideration in communications networks. One method of network management that may be suitable for use in future networks, is the so called policy-enabled networking. An example of the policy-enabled networking is QoS provisioning using the so-called ‘DiffServ’ architecture. ‘DiffServ’ refers to the IP Differentiated Service architecture, where QoS provisioning is obtained by marking data units. Different marked packets will receive a different priority in queuing and/or scheduling of nodes.
The Internet Engineering Task Force (IETF) has specified resource reservation signaling protocols, such as RSVP [R. Braden et al.: “Resource ReSerVation Protocol (RSVP)—Version 1 Functional Specification”, RFC 2205, September 1997], and different QoS models, such as Integrated Services [R. Braden, et al.: “Integrated Services in the Internet Architecture: an Overview”, RFC 1633, 1994], [J. Wroclawski: “The Use of RSVP with IETF Integrated Services”, RFC 2210, September 1997] or Differentiated Services [S. Blake, et al.: “An Architecture for Differentiated Services”, RFC 2475, 1998], for providing QoS in an IP network. In the Next Steps In Signaling (NSIS) Working Group (WG) of IETF a new QoS signaling protocol, aiming to meet the requirements of 3G networks and different real time applications, is under development.
The future NSIS protocol will support different QoS models and operation modes including Resource Management in Differentiated Services (RMD) [L. Westberg et. al.: “Resource Management in Diffserv (RMD): A Functionality and Performance Behavior Overview”, Protocols for High Speed Networks 7th IFIP/IEEE International Workshop, PfHSN 2002, Berlin, Germany, Apr. 22-24, 2002. Proceedings Series: Lecture Notes in Computer Science, Vol. 2334 Carle, Georg; Zitterbart, Martina (Eds.) 2002, X, 280 pp., Softcover ISBN: 3-540-43658-8], patent publication WO2002076035A1]. RMD is a scalable and dynamic resource reservation method based on DiffServ and it is able to work together with standard IP routing protocols. This allows fast re-routing in case of link or node failure, which is one of the major advantages of IP networks comparing to other transport technologies such as AAL2/ATM [3GPP TSG RAN: “IP Transport in UTRAN Work Task Technical Report” 3GPP TR 25.933, 2003].
In RMD scalability is achieved by separation of the complex per domain reservation mechanism from the simple reservation mechanism needed for a node. Complex functions are performed at edge nodes and core nodes are involved only in simple operations. In such a system edge nodes perform complex operation and store per-flow information while core nodes in the domain perform simple operation and do not store per-flow states. In such a resource management system, two basic operation modes can be distinguished: normal operation and fault handling. Normal operation includes making a new reservation, refresh reservations, and tear down reservations. Fault handling is needed if quality-of-service sensitive flows experience service degradation due to congestion. Basic features of normal operation and fault handling operation modes are described in A. Császár et al.: “Severe Congestion Handling with Resource Management in DiffServ on Demand”, In proc. of the Second International IFIP-TC6 Networking Conference, Networking 2002, pp. 443-454, May 2002, Pisa, Italy.
Severe congestion is considered as an undesirable state, which may occur as a result of a route change. Typically, routing algorithms are able to adapt and change their routing decisions to reflect changes in the topology (e.g., link failures) and traffic volume. In such situations the re-routed traffic will have to follow a new route. Nodes located on this new path may become overloaded, since they suddenly might need to support more traffic than their capacity. The resource management protocol in reaction to severe congestion has to terminate some flows on the congested path in order to ensure proper QoS for the remaining flows.
Congestion occurrence in the communication path has to be notified to the edge nodes of the affected flows, since core nodes do not have per flow identification. The congestion handling control loop consists of the following steps: (1) A core node that detects congestion marks passing packets, which are forwarded to an egress node. This way, (2) the egress node learns the overload ratio and decides accordingly which flows should be dropped. For these flows the egress node generates and (3) sends a report to an ingress node to reduce the traffic volume injected by the ingress node. This signal could be a RSVP tear down message or error message or NSIS response or any other kind of message describing the overflow of traffic volume. Upon reception of this signalling packet, (4) the ingress nodes terminate the appropriate flows.
The congestion algorithm described above and which is used also in the original RMD concept over-reacts congestion events terminating more flows than necessary to cease congestion. This effect can be seen as an “undershoot” in the link utilization graph of the affected links.
The reason of the over-reaction is the delayed feedback of the overload situation. After detecting the congestion situation, the core node notifies the egress nodes by marking data packets that pass through the node so that the sum size of the marked packets compared to all forwarded bytes is proportional to the overload. When the marked packets arrive at the egress node, it summarizes the size of marked and unmarked packets. Based on these two counters, the egress node calculates the overload ratio and decides which flow or flows to terminate. The core nodes do not have per flow information and they cannot have information about the previously marked packets per flow. In case of congestion they continue marking the packets until the measured utilization falls below the threshold. Since marking is done in core nodes, the decision is made at the egress node, and termination of flows are done in ingress node there is a delay between these events. In the ingress node the number of terminated flows is determined by previously marked packets. Thus, it can happen that there is no congestion any longer in the core node but the ingress node still terminates a number of flows determined in a previous time interval when congestion was detected.
We have set ourselves the objective with this invention to improve the solutions described above by handling the congestion more effectively in a packet switched network domain especially in an IP domain.